The following description relates to an object-based framework that provides a basis for integration of backend elements at a user interface level.
There are several ways to design and implement applications. Typically, the application determines the items that can be handled by the application, and the exclusive operations available to the items. For example, to read email, an email application is used, and to create an electronic document, a separate text processing application is used. This approach can be convenient for the application developer, as the developer need only deal with his/her own context, and is not restricted in modeling different items. However, from a user's perspective, different tasks require different applications, each with a different notion of an item and perhaps with a different user interface. To handle an item, a user must select the appropriate application, perhaps toggling between several applications at one time to deal with several different items. Typically, each of these applications provides an analogous basic feature set for the user interface, for example, an object browser or a preview pane. However, each can look slightly different and typically it is not possible for one to handle objects provided by other applications.
Alternatively, separate applications may handle different aspects of the same abstract element, requiring a user to know what operation needs to be performed on an element and which application to select to perform the desired operation. Different applications can use different representations for the same data. A common database and data scheme for different applications that share the same data can address this problem, for example, the common database and data scheme provided by SAP® R/3® available from SAP AG of Walldorf, Germany, for its applications and different applications that share data. Alternatively, explicit matching and replication mechanisms can address the problem. However, even sharing (virtually) common data maintains an application-centric approach, and it can be difficult, if not impossible, to handle items of one application in another application.
So-called “frame applications” can handle items of some related applications. For example, the Microsoft Outlook® application is able to handle many different functions related to mailing, messages and tasks. However, these functions are integrated in one large application (namely, Microsoft Outlook) that handles its own folder management for organizing these items inside the frame application. In general, it is not feasible to extend the set of item types that can be handled by the application. This approach may provide increased user-friendliness over the separate-applications approach, but ultimately is just a new kind of larger application. A user generally cannot mix the user's items with items of other applications or application groups, and cannot organize items in his/her own way.
The World Wide Web allows multiple independent applications to run in the same frame, linked together with loosely coupled links. In this sense, a web browser essentially can take the role of an operating or window system, in that the browser provides a desk or work place that can be filled with different types of items, all in the same frame. An enterprise portal is an example of a web-browser-based frame application that facilitates the presentation of disparate resources to a user.
In general, the separate-applications approach still prevails, and in this case a user-interface abstraction referred to as a “launch pad”, which is a substitute for complex menu structures, may be used to launch applications running independently in different explicit or simulated sub-frames.